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Abstract 

Controls systems are an increasingly important component 
of turbine-engine system technology. However, as engines 
become more capable, the control system itself becomes ever 
more constrained by the inherent environmental conditions of 
the engine; a relationship forced by the continued reliance on 
commercial electronics technology. A revolutionary change in 
the architecture of turbine-engine control systems will change 
this paradigm and result in fully distributed engine control 
systems. Initially, the revolution will begin with the physical 
decoupling of the control law processor from the hostile 
engine environment using a digital communications network 
and engine-mounted high temperature electronics requiring 
little or no thermal control. The vision for the evolution of 
distributed control capability from this initial implementation 
to fully distributed and embedded control is described in a 
roadmap and implementation plan. The development of this 
plan is the result of discussions with government and industry 
stakeholders. 

Nomenclature 

CLP Control Law Processor 

DECWG Distributed Engine Control Working Group 
ECU Engine Control Unit 

FADEC Full Authority Digital Engine Control 
I/O Input/Output, specifically conversion between 

analog and digital domains 

ITAR International Traffic in Arms Regulations 

Introduction 

There have been at least two revolutionary changes to the 
architecture of turbine-engine control systems since the 
invention of the jet engine. The first was the application of 
electronics (Ref. 1) to supplement, and eventually replace, the 
intricate hydro-mechanical controls then in standard use. 
While hydro-mechanical controls were certainly capable of 
providing acceptable control functionality, their size, weight, 
and expense constrained the ability to expand the number of 
control variables, which is a measure of control system 
complexity. The compactness and flexibility of this early 
electronics technology enabled the increase in complexity 
even though the initial capability and reliability (Refs. 2 to 5) 
of the primitive electronics were lacking by today’s standards. 


Early in this period, electronics were limited to supervisory or 
trim functions. Over time, many of the initial deficiencies 
were rectified and electronics provided innovations (Refs. 6 
and 7) which far surpassed the capability of hydro-mechanical 
control. Eventually, electronic systems would advance to the 
point that they were capable of performing as “full authority” 
meaning they could control the entire operation of an engine 
from start-up to shutdown according to the pilot’s throttle 
command. 

The second revolutionary change to control architecture 
occurred when full authority control was implemented with 
digital electronics and software, known as a full authority 
digital engine control (FADEC) (Refs. 8 to 20). This change is 
not significant because of the transition from analog to digital 
electronics, but because it represents a change in control law 
implementation from the physical domain of hardware to the 
virtual domain of software. The unlimited flexibility of 
software provided an unsurpassed capability for quickly 
implementing system improvements without the need to make 
hardware modifications. Whereas analog electronic control 
was a representation of individual, localized hydro-mechanical 
control functions, software-driven control architecture 
consolidated all of the engine control laws in one physically 
central location from which it could be easily modified. 
Consequently, the control laws themselves have became much 
more aware of the system state, limited mainly by the 
available computational power (Ref. 21). This centralized 
control hardware architecture, circa 1985, remains the state-of- 
the-art for present-day turbine propulsion systems. 

Early hydro-mechanical controls were, in effect, distributed 
control systems. Ironically, the next revolutionary change in 
control architecture will replicate this physical distribution of 
control functionality; however, it will also preserve the 
unifying centrality of FADEC architecture. This will be 
achieved through a networked system of embedded electronic 
controls. Not surprisingly, these changes are being driven by 
familiar constraints such as weight, volume, and cost as well 
as new concerns about the expanding complexity of engine 
and integrated vehicle control. 

There is a dichotomy of the driving forces behind 
revolutionary change in turbine engine control architecture 
that is representative of the need to reconcile present and 
future risks. That is, those involved with the future of present 
production systems are prone to be more cost-driven in their 
goals while those concerned with as-yet-to-be-designed 
systems tend to be more capability-driven. In actuality, the 
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forces for cost-control and capability need to be reconciled for 
the revolutionary change in control architecture to occur. 

Notional descriptions of traditional and distributed control 
architecture are depicted in Figure 1 and Figure 2. Distributed 
control, in its fully realized form, would embed highly- 
integrated electronics into each control system device so that 
they could communicate over a common communication 
network. 

Distributed engine control architecture will not be achieved 
as a single step change; rather it will occur in a progression of 
changes as new technologies enable the partitioning of control 
functionality across the entire environment of the engine 
system. Distributed control technology is largely, but not 
completely, based on improving the capability, packaging, and 
availability of electronic systems and components. This 
investment will enable them to survive in extreme conditions 
while requiring minimal need for isolation from the ambient 
thermal environment. Even though significant high 
temperature electronics capability currently exists, it has been 
beyond the means of individual investors to create the full 
range of capability necessary to effect a change in system 
architecture. 

The conclusion that distributed control architecture is 
necessary for future engine systems is not based on a “solution 
in search of a problem.” It is based on what has been the trend 
in mainstream control system design for at least the last 
decade and, more importantly; it is based on in-depth 
discussions with stakeholders in the aero-engine controls 
community. The Distributed Engine Control Working Group 
(DECWG) has been the mechanism to discuss these relevant 
control system issues. The DECWG includes representation 
from US government and industry and its members are from 
virtually every aspect of propulsion control from customers, to 
engine manufacturers, to suppliers. 

What follows is an in-depth examination of the state of 
engine control hardware systems from the perspective of 
members of the DECWG. This is followed by a vision and 
roadmap, with specific objectives for creating the fundamental 


controls technologies to enable distributed control systems. 
Finally, a discussion of the specific technical challenges 
impeding control system design on turbine engine systems is 
outlined. 

Perspective 

Stakeholders in the DECWG fall into categories such as 
end-users, engine manufacturers, system integrators, suppliers, 
and small businesses. Each stakeholder operates with a 
specific set of objectives, needs, and constraints which 
influence their participation and willingness to collaborate 
with each other. Intellectual property is a central issue. As in 
any business relationship there is competition within the 
group, but there is also the realization that without 
collaboration there can be little progress toward substantive 
change. In the absence of government regulations or 
contractual requirements for a specific architecture, both of 
which are highly unlikely, the case for distributed engine 
control must be made on the basis of technical merit and/or 
business objectives. It is important to understand this aspect of 
the technology in order to find a common path for 
collaboration. 

End-Users 

End-users generally fall into two categories: military or 
commercial. End-users tend to look at engine system level 
metrics such as performance (e.g., thrust, fuel burn, noise, 
emissions, responsiveness, stability), weight (also a subset of 
performance), and life-cycle cost when evaluating propulsion 
systems. In general, the specific technology on board an 
engine is of lesser importance to end-users as long as the 
aforementioned system metrics are acceptable. Government 
research programs are also geared toward system level metrics 
and thus have similar interests as end-users in achieving the 
end goals. 
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Figure 1. — A notional depiction of the traditional centralized 
engine control architecture. 



Robust, digital 
communications 


Figure 2. — A notional depiction of distributed control 
architecture. TIM is transducer interface module as 
defined in IEEE-1451. 
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End-user life-cycle costs include acquisition, operating and 
maintenance costs. Operating costs are largely related to fuel 
burn while maintenance costs include those related to keeping 
a system in a state of availability. Since fuel is by far the 
greatest cost for an engine system over its life cycle there is 
intense interest in technologies that reduce fuel burn. System 
availability is important to the end-user because it affects 
mission success for military users and profitability for 
commercial users. System availability is directly related to 
component reliability and the capability to quickly diagnose 
and repair problems when they occur. Demonstrating how 
control system architecture impacts these metrics for end-users 
is critical to gaining their support and generating pull for new 
controls technology. 

Acquisition costs increase as technology is added to a 
system, at least initially. Customers accept new technology 
when they receive a demonstrable benefit but they resist 
buying more capability than they need. In lieu of customer 
pull, regulatory measures are, in general, the only other 
method of integrating new technology in engine systems. 

Military users and government research programs have an 
interest in the development of distributed control because they 
often have a longer term view of engine systems and their 
future limitations. Even so, these efforts have always focused 
on targeted applications and have achieved limited success in 
advancing the technology to production systems. The 
fundamental roadblock is the initial cost of developing the 
appropriate high temperature electronics. No one, including 
customers, end-users, government programs, industries or 
business has been willing or able to provide the investment 
necessary to resolve the remaining technical challenges and 
make available affordable electronic components for creating 
viable distributed architectures. From their perspective, the 
narrowly defined need has not been imminent enough to 
justify the expense of this technology. 

However, that is beginning to change. New engine control 
technologies for combustion, compressor stability, and flow 
control tend to be high-bandwidth, computation-intensive 
technologies that will drive the control law processing 


Core Mounted - Fuel Cooled 



Figure 3. — Engine core mounted electronics require cooling 
which increases system weight and complexity. 


requirements of future engine control systems. Additionally, 
engine diagnostics and prognostics, and adaptive control 
technologies are expected to place an increasing burden on the 
centralized Engine Control Unit (ECU) hardware. A 
commensurate investment to ensure control architecture does 
not become the limiting factor in engine systems is warranted. 

Engine Manufacturers 

There is tremendous variability in the different types of 
engine systems in response to the needs of customers. 
Customers do not buy technology, they buy capability, and 
their time frame of reference is often very short in contrast to 
the life expectancy of the engine which can be 20 years or 
more. This puts pressure on manufacturers to develop 
technology to solve immediate problems that have short term 
payoff. This type of technology is incremental or evolutionary 
in nature, not revolutionary. Still, the accumulation of 
incremental changes in the engine system over time leads to 
the development of system constraints which eventually 
require higher risk approaches to overcome them. 

Over time and with many contributing technologies, engine 
system cores have become smaller and lighter for a given 
thrust value while operating at significantly hotter 
temperatures. For military systems, this translates into 
significant challenges for mounting control electronics on the 
hot engine core as shown in Figure 3. Commercial engines, 
which traditionally mount electronics on the cold fan casing 
shown in Figure 4, are also affected. The drive toward higher 
bypass engines, with either shrouded or open fans, is pushing 
electronic assemblies off the fan casing. The choice becomes 
mounting electronics on the hot core, akin to military engines, 
or at greater distances from the engine control elements. Both 
choices increase system weight from either additional cooling 
apparatus or longer cable harnesses. 

Engine systems are developed for a wide variety of 
applications and the design of each control system is peculiar 
to that engine, creating a tremendous cost and schedule driver 


Fan Case Mounted - Air Cooled 
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Figure 4. — Engine fan casing mounted electronics are in a 
cool environment. 
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for manufacturers. While there is a great deal of similarity in 
the function and use of these control system components, there 
is very little reuse or commonality in the control hardware. 
This is primarily because emphasis is placed on meeting 
customer requirements and each design is highly optimized for 
that solution. 

Engine systems are typically long-lived items and will be 
modified or upgraded over their life span. The reason can be 
due to performance upgrades requested by the customer, but 
are often unscheduled due to common maintenance coupled 
with electronic component obsolescence. In either case, the 
result is a lengthy redesign and requalification process to 
satisfy certification authorities. 

Electronic component obsolescence is a complete wildcard 
in the design of engine control systems. Virtually the same 
electronic parts found in consumer applications are used in 
engine controls. The constant improvement in commercial 
electronics due to consumer demand drives components out of 
production after only a few years. However, these control 
system parts are needed to support an engine system lifespan 
of two decades or more. Lifetime buys of an electronic part 
are often the only recourse. 

All of these issues are incorporated in the research, 
development, test, and evaluation costs incurred by the 
manufacturer and are absorbed by the customer as part of the 
acquisition cost of the engine or upgrade. While the 
manufacturer can pass these costs along, they are not trivial 
and tend to delay (Ref. 22) the customer’s decision to 
purchase new systems or upgrades. 

Engine manufacturers are interested in distributed control 
technology for several reasons. It is becoming apparent that 
controls could become a limiting factor in future systems and 
manufacturers are beginning to recognize that it will affect 
their competitiveness. But there has always been interest in 
this technology for its potential to decrease the entire engine 
design cycle time and reduce the substantial non-recurring 
engineering costs associated with any new design or 
modification. Manufacturers also recognize the opportunity 
for additional customer value in terms of improved reliability 
and fault detection and system weight reduction. Regardless, 
the expense of developing the technology and the lack of 
customer pull to cover the costs has placed the technology 
beyond the reach of any individual engine manufacturer. 

System Integrators 

Manufacturers work closely with a system integrator to 
implement the engine control. However, the definition of the 
control system often begins after the preliminary design of the 
engine is complete. This limits the options available to the 
system integrator and also puts disproportional pressure on the 
need to reduce control system cost and weight. As mentioned 
above, innovation is generally reserved for resolving the near 
term issues under the constraints of the existing mechanical 
system. Most of this innovation goes into increasing the 
density of packaging in the ECU while the addition of new 


control functions is often determined by the impact to weight 
and cost. 

The ECU is the center of the control system as it interfaces 
with virtually every electrical device on the engine and 
communicates with the airframe control as well. It also 
receives electrical power feeds from the engine and/or 
airframe and provides the specific conditioned power needs of 
every device in the control system. Due to the centrality of the 
ECU it is very sensitive to changes anywhere in the engine 
control system. 

Across engine platforms, there is a great deal of similarity 
in control element functions; measurements such as 
temperature, pressure, speed, flow, and position; and actuation 
such as fuel metering, bleeds and variable stator geometry. Y et 
few of these common control element functions result in 
shared components between engine models. Instead, they are 
uniquely defined at the hardware level for each engine system. 

The ECU assembly contains these unique and redundant 
interfaces for all of the control input/output (I/O). This drives 
the complexity of the circuitry within the ECU, especially the 
analog circuits which must accommodate each unique control 
element. The complexities of the internal details of these 
interfaces would be completely masked by the environmental 
enclosure if it were not for the multiple, high pin count 
connectors on the outside walls. The number and size of these 
connectors often dictate the dimensions of the enclosure. 

Any change to the control design, whether initial design 
iterations or a field upgrade requires a complex 
synchronization of the supply chain, the hardware 
documentation, and the configuration management system. 
One change can affect several components. Within the ECU, 
circuit boards could be modified. Depending on the extent of 
the modifications this could ripple through to require a 
redesign of the power supply, package connectors, and even 
the mechanical design of the enclosure. The latter must be 
checked against the available mounting envelope on the 
engine. In addition, the system as a whole has to be qualified 
for flight worthiness which requires a substantial investment 
in capital and time. As a result, engine control system 
modifications at any point in the life cycle can cost as much as 
the original design. 

System integrators are interested in distributed control for 
the obvious impact it would have on the design cycle. If every 
control device implemented a common interface for 
communication and power it would greatly simplify 
integration. Changes in any one device would be firewalled by 
the common interface so that hardware modifications would 
be localized to that device. This would largely mitigate the 
electronic obsolescence issue. Requalification of the system 
could be achieved with rigorous requalification of a single 
control system component and adherence to the interface 
standard. 

With many of the complex hardware integration issues 
resolved by distributed control, integrators could focus more 
resources on value-added items such as system health 
monitoring and adaptive control. 
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Suppliers 

Suppliers provide the components of the engine control 
system. Devices such as pressure and temperature sensors, 
speed indicators, solenoids, motors, and electrically operated 
hydraulic actuators. Often these devices are complex 
assemblies such as fuel controls with integral sensors and 
actuators. These devices sometimes begin from a common 
design but are highly modified electrically and mechanically 
for each specific application. High reliability and low cost for 
the specified accuracy are the drivers. The non-recurring 
engineering cost for these components is high because of their 
uniqueness and the need to supply these components for the 
engine lifetime. 

Suppliers are interested in distributed control technology 
because it provides additional opportunities for them to 
compete in what is close to a commodity market. In a 
distributed system, standard interfaces allow the supplier to 
leverage common designs which could meet the needs for a 
variety of engine systems. Electrical as well as mechanical 
interfaces could be standardized thereby reducing non- 
recurring engineering costs, simplifying the task of the system 
integrator, and providing resiliency to system changes. 

Suppliers could also significantly increase innovation 
because of the use of distributed technology. Embedded 
electronics provide new functionality enabling suppliers to 
concentrate on value-added capabilities similar to what is 
described in the IEEE 1451 specification (Ref. 23). For 
instance, actuators could be equipped with embedded local 
loop closure to offload the control law processor (CLP) and 
improve responsiveness. Sensors could incorporate technology 
to maintain accuracy over time and/or under varying 
conditions while identifying those modes of operation to the 
CLP. Perhaps some of the most obvious value-added 
capabilities will be related to improved system reliability and 
fault detection, accomplished through the use of built-in test 
and in-situ interrogation of system components. 

Schemes that are much more sophisticated could be 
implemented. For instance, high bandwidth data from a 
pressure or vibration sensor could be filtered through a signal 
processor to quickly detect a compressor stall signature 
without dumping large amounts of data over the network to 
the CLP. These same devices could sense the engine operating 
mode by monitoring network communication data and 
internally compensating its detection parameters based on 
engine speed or other conditions. 

Lastly, many component upgrades or device variants could 
be accomplished just by modifying the embedded firmware. 

Small Business 

Small businesses find it difficult to break into established 
markets like turbine engine control because of the established 
competition. Manufacturers assume significant liability for the 


product and therefore levy a requirement for high-reliability 
and low risk. Manufacturers vigorously protect intellectual 
property and have a need for a long term, dependable 
relationship which favors established suppliers. 

Small businesses are interested in distributed control 
because the entry barriers are lowered for everyone. While the 
requirements for high reliability do not change, the risk is 
significantly reduced by the use of a standard interface 
specification. If the device does not prove to be adequate or 
the small business fails, there are other suppliers to fill the 
need in a short time frame. Intellectual property is protected 
for both parties since the function and embedded intelligence 
is firewalled through the standard interface. 

The issues described in the Perspective section are largely 
associated with the processes, logistics, and business case for 
turbine-engine control systems. Certainly these are barriers to 
achieving successful distributed systems, especially when 
viewed from a narrow perspective. However, when viewed 
from a wider perspective, the performance advantage and 
value of distributed architecture for every stakeholder is 
readily apparent. Finding common ground for stakeholders to 
leverage each other’s investment will be the key to success. 
The vision and roadmap provides a template for that 
interaction. 

Vision and Roadmap 

The vision for implementing distributed engine control 
occurs as a progressive capability described in three milestone 
architectures beginning with the present day centralized 
architecture, shown in Figure 5. Successive capabilities are 
described as the Core I/O architecture, Networked Control 
architecture, and Fully Distributed architecture. Each step 
signifies a major milestone in hardware capability that is 
enabled by advancements in high temperature electronics. The 
significant features of each architecture are described in the 
subsequent sections. 



! • Analog Point-to-Point Connections 

from ECU to Control Elements 

• Unique Interfaces to each Control 
Element 

Figure 5. — The centralized engine control architecture 
typical of present day turbine engine systems. 
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Core I/O Architecture 


The Core I/O architecture, shown in Figure 6, is designed to 
achieve early success with distributed architecture by limiting 
the scope of the hardware changes and keeping most of the 
supply chain intact. Nevertheless, it is expected to achieve real 
system improvements in terms of weight reduction and to 
begin addressing the electronics obsolescence issue, at least 
with the most expensive electronics performing control law 
processing. This milestone architecture will demonstrate a 
capability with high temperature electronics and modular 
systems that addresses long-term concerns regarding 
increasing control content on engine systems. It is targeted to 
be achieved in a five year time frame. 

The Core I/O architecture essentially breaks the ECU into 
two components, a CLP and a Data Concentrator. The 
function of the CLP is to perform digital data processing 
operations only. It has two primary interfaces; airframe 
communications, as before, and a new digital communication 
link to the Data Concentrator to effect engine control. 

The CLP, by virtue of digital communication and the low 
weight harness to the Data Concentrator, is free to be located 
to a more suitable environment, even off-engine. The package 
becomes smaller and lighter because at least 50 percent of its 
functionality has been removed. The interfaces are 
standardized allowing the processing components inside to be 
more easily upgraded to the latest technology without 
impacting the engine system as a whole. Even the internal 
design of the CLP package could be standardized to conform 
to a ruggedized bus standard instead of the highly customized 
circuit boards now used. 

The all-digital CLP provides an easy integration path for 
new technologies in control, prognostics and diagnostics. In 
fact, the latter could be implemented as a stand-alone function 
separate from control so that it does not require the same 
degree of qualification. 

The Data Concentrator contains all the I/O function and 
power distribution of the previous ECU. It is fabricated with 
high temperature integrated circuits that enable it to be 
mounted in a suitable location on the core, where the ambient 
environment is expected to be less than 170 °C, without virtue 
of fuel cooling or other technologies that increase weight. The 
engine control sensors and actuators interface directly to the 
Data Concentrator as they did with the centralized ECU except 
that the harness length is reduced in the commercial engine 
application because it does not extend all the way to the fan 
casing. 

The successful implementation of the Core I/O architecture 
will lower system weight. An industry study of a similar 
architecture on a small turboshaft engine documents control 
system weight reduction of approximately 10 percent based on 
the present limited selection of high temperature electronic 
components (Ref. 24). Other manufacturers have voiced 
similar results; however, these are highly subjective to 
baseline assumptions and the overall goals of a particular 
engine system. Progress in temperature capability and high- 


T = 5 vears 



Figure 6. — The Core I/O Architecture is the first step into 
distributed control on turbine engines. It is enabled by 
core-mounted high temperature electronics in an 
uncooled Data Concentrator. 

density packaging of integrated circuits can improve this 
weight reduction by minimizing the size of the Data 
Concentrator. 

Networked Control Architecture 

After achieving the capability articulated in the Core I/O 
architecture, the goals will be to improve modularity for 
innovation, simplify integration of new control technology 
onto the engine system, and enable additional weight 
reduction. This milestone capability is expressed as the 
Networked Control Architecture and is shown in Figure 7. In 
this architecture, the CLP remains as a modular device capable 
of integrating new commercial processor technology as it 
becomes available. Simplification of the Data Concentrator 
beyond the previous architecture is achieved by distributing 
the data conversion functions out to the system control 
elements. In contrast, the system control elements become 
more complex but also more capable by virtue of embedded 
electronics. This capability is to be achieved within a ten-year 
period. 

The Network Control Architecture represents a further 
distribution of control functionality. Moving the data 
conversion, or I/O function out of the data concentrator 
enables the interface between all control system elements to 
become digital and modular. Furthermore, this interface can 
be made common by using a shared physical layer 
communication bus standard and protocol. For control signals, 
the data concentrator function would be analogous to a 
communication bridge controlling information flow between 
various networks. 

Modularity is a key capability to enabling flexible and 
scalable control system design and the potential to share a 
wide supplier base of engine control elements. It has 
significant impact to obsolescence and major lifecycle cost 
reductions related to system availability. 

The Data Concentrator will retain responsibility for power 
distribution as in the previous architecture. However, the 
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T = 10 years 



/Processor 

Commercial Silicon 
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• Networked Control Elements 
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• Smart Sensors and Actuators 
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Figure 7. — The Networked Control Architecture further 
distributes control capability. It is enabled by embedded 
high temperature electronics in sensors and actuators. 


T = 15 years 



Control Law Processor 
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No Data Concentrator 
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Fully Embedded Subsystem Control 
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Figure 8. — The Fully Distributed Architecture represents a 
mature distributed technology. It is enabled by high 
temperature embedded subsystems with significant control 
capability. 


complexity of the power distribution is likely to be greatly 
reduced based on the unique I/O requirements being moved to 
the system effectors. This will allow the power interface to be 
standardized or at least simplified. In effect, the Data 
Concentrator package becomes quite small even with respect 
to Core I/O architecture. 

The sensors, actuators, and subsystems representing control 
elements must increase in complexity to enable this 
architecture. Since one of the primary objectives of distributed 
control is to reduce weight, how this complexity is embedded 
is critical. It will be necessary to develop highly integrated 
electronic components to achieve a minimal impact on the 
weight of these control elements. Fortunately, performing data 
and power conversion in the smart devices will significantly 
reduce the weight of the wiring harnesses connecting control 
elements with the Data Concentrator. 

Control elements exist in locations spread across the engine 
making it more difficult to control the thermal environment to 
which the electronics are exposed. In most cases, the local 
environment will be such that a junction temperature of 
225 °C will be adequate. However, in some cases there will 
likely be a need for electronics capable of functioning in an 
ambient environment above 300 °C. The temperature 
capability of electronics is significant to weight control. The 
higher the temperature in which electronics can be reliably 
operated, the lower the weight penalty will be for thermal heat 
dissipation. 

The weight reduction goals for this architecture are as 
follows: i) A combined CLP and Data Concentrator weight 
less than the centralized ECU; ii) Negligible increase in 
system control element weight; iii) Wiring harness weight 
reduction on the order of 80 percent with respect to centralized 
architecture. 

The intent of this milestone architecture is not to force all 
devices to become intelligent with embedded electronics; 
system designers must make that decision. The intent is to 
create a capability to improve the system level metrics that are 
important to customers and stakeholders. It is likely that some 
hybrid of the Core I/O and Networked Control Architectures 
will lead to optimal results. 


Fully Distributed Architecture 

The Fully Distributed architecture, shown in Figure 8, 
represents the natural progression in capability of high 
temperature electronics as customer technology pull drives 
continuous improvement. At this future time, the 
advancements in electronics in the 300 to 500 °C environment 
will no longer be performance limited relative to present day 
commercial silicon although the market size will still be 
relatively small. These electronics will bring high data 
processing capability to the engine environment although still 
lagging behind the capability of common commercial 
electronics. The major advancements in control capability will 
be in embedded control processing and high data rate 
communications above 300 °C. This capability is expected to 
be achievable in a 15-year time frame. 

In this architecture, the function of the data concentrator 
becomes obsolete as the communication capabilities of the 
smart devices enable them to communicate directly to the 
CLP. It is very likely that the communication medium will 
take advantage of wireless technology for the lowest possible 
control system weight. Of course, parasitic power technology 
would be required to make these devices viable. 

The primary advantages of this architecture are; i) ultimate 
weight reduction of controls due to high-density, high- 
temperature electronics packaging, wireless networking, and 
parasitic power, ii) ubiquitous system knowledge due to near 
“weightless” wireless instrumentation embedded in 
components including the hot gas path, iii) very high 
reliability due to multipoint validation of system parameters. 

Technical Challenges for Distributed 
Turbine Engine Control 

Discussions within the DECWG have also revealed many 
of the most significant technical challenges that must be 
overcome to realize distributed engine control. These technical 
challenges are networked communications, power distribution, 
high temperature electronics, control/stability, and systems 
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integration. These “tall pole” issues are areas of common 
interest among members of the DECWG. They are considered 
precompetitive technologies, with the notable exception of 
control/stability, and members have shown an interest in 
collaboration to achieve their resolution. The issue of 
control/stability is an area of competitive advantage. It is 
strongly protected intellectual property, potentially ITAR 
related, and it is not discussed in this paper. 

Networked Communications 

The fundamental precept of distributed control in the engine 
application is the separation of the processing-intensive 
system-level control law algorithms from the I/O functions 
(specifically conversion between analog and digital domains) 
and the local control loops. This is necessary due to the 
realization that there will always be a dependence on 
commercial data processing electronics in the turbine engine 
control application. 

Commercial processors are defined as those targeted at, and 
driven by, consumer electronics applications such as personal 
computers, cell phones, and video equipment. These electronic 
components have an insurmountable technology development 
lead of 30 years or more on high-temperature electronic 
components. They supply consumer devices that will likely 
never encounter, or be designed for, the type of environment 
experienced on a turbine engine. In addition, they are 
produced in huge volumes for the commercial markets and 
therefore are extremely cost efficient. In fact, they are virtually 
the same devices currently used in present ECUs but packaged 
inside of nigged, thermally controlled enclosures. 

The objective of segregating the processing-intensive, high- 
level control law function is to place the commercial 
electronics dependent hardware in a more benign environment 
where the system impact of packaging is less severe. This 
impact is measured in terms of additional weight and cost for 
cooling, vibration, electromagnetic interference, etc., on the 
exposed engine. In distributed control, the desire is to enable 
an “unconstrained” CLP which implies it is capable of being 
placed by the system integrator or engine manufacturer to the 
most suitable location with minimal system impact. 

Analog I/O functions, in contrast, must remain on the 
engine close to the transducers. There are several arguments 
for this, such as electrical noise, which are well beyond the 
scope of this paper. However, in terms of direct engine system 
benefit, weight reduction is the first order effect. The entire 
I/O process is a series of conversions, beginning (or ending) 
with a physical quantity and ending (or beginning) with a 
digital representation of that quantity. Copper wires are 
typically the physical media connecting each of these steps 
and, in general, the mass and volume of that media are greatest 
near the transducer due to the number of conductors. The 
complexity of the individual electronic interfaces is mentioned 
in previous sections. The closer to the transducer that the 
signal can be digitized, the lower the harness weight will be 
due to sharing of the interconnecting media and smaller 


conductors. Note that harness weight is the same reason why 
present centralized architecture locates the ECU on the engine. 

Although I/O functions require electronics, these types of 
devices are less prone to the commercial market-driven 
obsolescence issues of high-performance microprocessors 
used for control law processing. In that regard, they are less 
likely to change over the life of an engine system and are more 
suitable as a target for high-temperature electronics 
technology development, which will be discussed 
subsequently. 

To enable the separation of the control law processing 
function and the I/O function requires a suitable 
communication network. Within present ECUs, this 
communication is handled on the internal system bus of the 
computer at very high speeds, in a tightly controlled hardware 
process, over a very short distance. For the minimum 
distributed system, the total quantity of data passing in both 
directions through the I/O process must be transmitted 
between the I/O function and the CLP. This defines the 
minimum capability (Ref. 25) of the network because it 
doesn’t accommodate future control system growth or the 
expansion of data flowing on the network for non-control 
functions such as health monitoring and fault isolation. 

Implementation of a common communication standard for 
the turbine engine becomes a complex problem due to 
multiple conflicting requirements. First, the communication 
network must not contribute to control instability (Ref. 26). 
Typically this means data throughput must be adequate and 
deterministic. Meanwhile, fault isolation is perceived as an 
area of considerable strength in distributed systems because of 
the intelligence embedded at lower levels of the system. 
However, this advantage can drive throughput well beyond the 
pure control requirement. Lastly, the use of high temperature 
electronics will temper communication capabilities with 
respect to modern low temperature capabilities, at least 
initially. The challenge is to resolve the true communication 
need for the application and focus on the common 
development of capable high temperature hardware. With an 
eye toward future development, the communication system 
should be considered a “modular” component so that it has an 
upgrade path with forward/backward compatibility. 

Power Distribution 

Present engine control systems implement the power 
distribution function through the ECU. This is logical since 
the centralized ECU can have unique power requirements for 
each I/O channel based on the needs of the I/O device. As 
control systems become more distributed, the uniqueness of 
the power requirement must migrate toward the control 
elements. This is an implication of the standard interface 
which supports the modularity of distributed control as well as 
the need to minimize the complexity and weight of the wiring 
harness. In a distributed control system, the need for a reliable, 
fault tolerant power must be evaluated against the desire to 
minimize weight or any other system level benefit. 
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There are other implications as the power system becomes 
more distributed and is exposed to higher temperature 
environments. As with electronic components, temperature 
causes a de-rating of magnetic and other passive components 
which are used in power supplies. This could lead to problems 
with physical size or potential issues with electrical 
noise/susceptibility as switching supplies increase in 
frequency. 

Most important, however, is the need to fully understand 
failure modes and the need to maintain, if not improve, overall 
system reliability. 

High Temperature Electronics 

The common thread in describing the physical 
implementation of a distributed control and power system is 
the high temperature capability of the electronic components. 
Fundamentally, distributed architecture is about modularity 
and the host of benefits that are realized because of it. For 
present and near-term engine systems, this modularity can 
provide real reductions in system design and upgrade time. In 
the long-term, distributed architecture is about preserving the 
capability to absorb growth in control requirements. Flowever, 
if distributed architecture is to become a reality, it must do so 
without reducing present performance capability. 

This implies that a distributed system must be implemented 
without a weight penalty with respect to traditional control 
architecture. The reduction in wire harness weight will be 
significant in a distributed system, but it will only create a 
weight benefit if the new distributed components are packaged 
using technology that enables a high degree of integration with 
little or no thermal accommodation for the ambient conditions. 

Various electronic technologies do exist that have 
capability beyond the common 125 °C junction temperature of 
commercial silicon. Some of this technology is commercially 
available now while even higher temperature technology is 
showing significant performance capability in research 
laboratories. For turbine-engine control systems, the specific 
electronic technology is not important; however, the capability 
that the technology brings to the engine system control is. 

In the near-term, electronic temperature capabilities in the 
range of 225 °C junction temperatures will provide sufficient 
capability for initial forays into distributed control 
architecture. This limitation will likely enable operation in an 
ambient environment below 170 °C, which recognizes other 
constraints in the engine control system such as equipment 
fabricated with elastomers and aluminum. Much of the 225 °C 
technology currently exists in the commercial sector, 
developed through previous programs such as the Department 
of Energy sponsored Deep-Trek program in the 1990’s. 
However, there are notable capabilities that still need 
development such as nonvolatile memory, improved 
processors, stable passive components and magnetics, and 
high-reliability interconnects. 


As a whole, the electronics technology existing 
commercially is not properly packaged to meet the weight or 
reliability goals for distributed control in the turbine engine 
system. Improvements must be made in both the level of 
integration and the durability of parts in a high vibration 
environment. 

In the long-term, temperature capabilities above 300 °C are 
envisioned to enable fully embedded intelligent devices across 
the engine environment. This capability is at a significantly 
lower state of readiness but recent progress shows that the 
fundamental challenges are being resolved. Integrated 
electronic devices operating for extended duration (Ref. 27) at 
temperature as high as 500 °C have been demonstrated. 

Systems Integration 

As previously stated, distributed architecture is 
fundamentally about modular systems. However, the 
development and use of modular systems is itself a technology 
that needs to be developed. 

One of the primary cost drivers cited by industry is the 
flight certification process. Current engine systems require full 
requalification for new designs and modifications. In a 
modular distributed architecture, one of the main benefits, and 
reasons for industry participation, is the potential to qualify 
segments of the control system that are fully isolated from one 
another by means of digital communication and a rigidly 
controlled interface specification. Acceptance of these changes 
by regulatory agencies will require a significant burden of 
proof on the part of system designers and an arduous task of 
the adaptation of qualification processes and procedures. 

Distributed systems present major changes to system 
design, integration, and verification processes and affects the 
relationship with suppliers. These represent a major shift in 
culture for the industry. 

Development Plan 

The progression of architectures described in the preceding 
section is used to generate a common diagram shown in 
Figure 9. To execute this roadmap will require a collaboration 
of government and industry that is designed to eliminate 
existing technology and cost barriers while enabling system- 
level competition and protection of intellectual property. 

The focus of the collaboration will initially be on the 
development of an electronic parts library for engine control 
functions that will be capable of sustained operation in 
ambient temperatures found on the engine core. The electronic 
components for near-term architectures are being identified so 
that they can be developed and properly packaged to meet the 
environment, weight, cost, and reliability constraints of the 
turbine engine system. Use of common components does not 
preclude competition of system level design. 
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Figure 9. — The development roadmap for distributed 
engine control. Architecture is enabled by capability. 
Capability is enabled by electronics. 


To complement this initial effort, and support the needed 
electronics capability of future control architectures, the 
continuous improvement of electronics capable of operating in 
elevated temperature environments, including above 300 °C, 
will be required. Much of this effort is taking place in research 
laboratories but is now being shaped by the needs and 
requirements of engine control architecture. 

What makes the entire effort most difficult is the limited 
aeronautics market size and the inherently limited electronic 
component volume which drives component cost. To increase 
component volume, and lower cost, may require collaborating 
with other industries that have common interests and 
overlapping requirements. Some of these industries may 
include energy production (such as oil and gas, geothermal, 
and solar), automotive, heavy industry (such as metalworking, 
chemicals, and other energy intensive processes), power 
generation, and military and aerospace, if these collaborations 
are to occur, they must be assembled in such a manner as to 
not dilute or deviate from the original aeronautics goals or 
result in increased costs. 

Assuming suitable electronic components become available 
at a price point that does not offset their benefit, distributed 
engine control systems for turbine engines will be achievable. 
It will then be up to industry to use the technology, in the 
innovative ways of competition, to meet customer need. 

Finally, to ensure success in the development of distributed 
systems that are driven by aeronautics system goals and 
government funding, industry must be required to demonstrate 
the technology under relevant conditions in a hardware-in-the- 
loop test facility. This will provide the necessary feedback to 
stakeholders to demonstrate their return on investment has 
been worthwhile. This last point will be simplified by the use 
of interface standards that enable various facets of the control 


industry to participate in an inclusive demonstration of 
distributed turbine engine control technology. 


Conclusions 

• A perspective on the benefits and implementation 
constraints of distributed control system architecture for 
turbine engines was described from the viewpoint of end- 
users, engine manufacturers, system integrators, suppliers, 
and small business. 

• Stakeholders state that near-term engine system 
constraints, especially temperature, and future control- 
based, performance-enhancing engine technologies will 
cause control system hardware to be a limiting factor in 
future engine performance. 

• The consensus of stakeholders is that distributed control 
architecture is possible and provides real system level 
benefits but is dependent on the availability of high 
temperature electronic components. 

• High temperature electronics with 225 °C junction 
temperature capability is commercially available with 
many, but not all of the necessary functions to enable 
distributed control. 

• Improved packaging of high temperature electronics is 
necessary to achieve an implementation of distributed 
control with system weight reduction. 

• High temperature electronics is unaffordable unless 
industry stakeholders collaborate on standardized parts 
libraries to increase volume and reduce non-recurring 
engineering costs. 

• If the electronic component price points cannot be met, 
manufacturers will not implement distributed control 
technology until customers generate sufficient technology 
pull to successfully fund its development. 

• A vision, roadmap, and implementation plan has been 
developed and is collaboratively being executed with 
stakeholders to develop the necessary electronics to 
implement distributed engine control. 
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